<!DOCTYPE html>
            
<HTML>
<HEAD>
<meta name="booktitle" content="Developing Applications With Objective Caml" >
 <meta charset="ISO-8859-1"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
<META name="GENERATOR" content="hevea 1.05-7 of 2000-02-24">
<META NAME="Author" CONTENT="Christian.Queinnec@lip6.fr">
<LINK rel=stylesheet type="text/css" href="videoc-ocda.css">
<script language="JavaScript" src="videoc.js"><!--
//--></script>
<TITLE>
 Memory Management by Objective CAML
</TITLE>
</HEAD>
<BODY class="regularBody">
<A HREF="book-ora086.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora088.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2> Memory Management by Objective CAML</H2>
<A NAME="@concepts200"></A>
<A NAME="@concepts201"></A>
Objective CAML's garbage collector combines the
various techniques described above. It works on two
generations, the old and the new. It mainly uses a <I>Stop</I>&amp;<I>Copy</I> on the new
generation (a minor garbage collection) and an incremental <I>Mark</I>&amp;<I>Sweep</I> on the
old generation (major garbage collection).<BR>
<BR>
A young object that survives a minor garbage collection is relocated to
the old generation. The <I>Stop</I>&amp;<I>Copy</I> uses the old generation as the <TT>to-space</TT>. When it is finished, the entire <TT>from-space</TT> is
completely freed.<BR>
<BR>
When we presented generational garbage collectors, we noted the
difficulty presented by impure functional languages: an old-generation
value may reference an object of the new generation. Here is a small example.


<PRE><BR># <B>let</B><CODE> </CODE>older<CODE> </CODE><CODE>=</CODE><CODE> </CODE>ref<CODE> </CODE><CODE>[</CODE><CODE>1</CODE><CODE>]</CODE><CODE> </CODE>;;<BR><CODE>val older : int list ref = {contents=[1]}</CODE><BR><CODE>(* ... *)</CODE><BR># <B>let</B><CODE> </CODE>newer<CODE> </CODE><CODE>=</CODE><CODE> </CODE><CODE>[</CODE><CODE>2</CODE>;<CODE>5</CODE>;<CODE>8</CODE><CODE>]</CODE><CODE> </CODE><B>in</B><BR><CODE> </CODE><CODE> </CODE><CODE> </CODE>older<CODE> </CODE><CODE>:=</CODE><CODE> </CODE>newer<CODE> </CODE>;;<BR><CODE>- : unit = ()</CODE><BR>

</PRE>

The comment <CODE>(* ... *)</CODE> replaces a long sequence of code in
which <TT>older</TT> passes into the older generation. The minor
garbage collection must take account of certain old generation
values. Therefore we must keep an up-to-date table of the references
from the old generation to the new that becomes part of the set of roots
for the minor garbage collection. This table of roots grows very little
and becomes empty just after a minor garbage collection.<BR>
<BR>
It is to be noted that the <I>Mark</I>&amp;<I>Sweep</I> of the old generation is incremental,
which means that a part of the major garbage collection happens during
each minor garbage collection. The major garbage collection is a <I>Mark</I>&amp;<I>Sweep</I>
that follows the algorithm presented on page&nbsp;<A HREF="book-ora086.html#sec-GC-gen">??</A>.
The relevance of this incremental approach is the reduction of waiting
time for a major garbage collection by advancing the marking phase with
each minor garbage collection. When a major garbage collection is
activated, the marking of the unprocessed regions is finished, and the
reclamation phase is begun. Finally, as <I>Mark</I>&amp;<I>Sweep</I> may fragment the old
generation significantly, a compaction algorithm may be activated after
a major garbage collection.<BR>
<BR>
Putting this altogether, we arrive at the following stages:
<OL type=1>
<LI>
 minor garbage collection: perform a <I>Stop</I>&amp;<I>Copy</I> on the young
 generation; age the surviving objects by having them change zone; and
 then do part of the <I>Mark</I>&amp;<I>Sweep</I> of the old generation.<BR>
<BR>
 It fails if the zone change fails, in which case we go to step&nbsp;2.

<LI> end of the major garbage collection cycle.<BR>
<BR>
 When this fails go on to step&nbsp;3.

<LI> another major garbage collection, to see if the objects counted as
 used during the incremental phases have become free.<BR>
<BR>
 When this fails, go on to step&nbsp;4.

<LI> Compaction of the old generation in order to obtain
 maximal contiguous free space. If this last step does not succeed,
 there are no other possibilities, and the program itself fails.
</OL>
The <TT>GC</TT> module allows activation of the various phases of the
garbage collector. <BR>
<BR>
A final detail of the memory management of Objective CAML is that the heap
space is not allocated once and for all at the beginning of the
program, but evolves with time (increasing or decreasing by a given
size). <BR>
<BR>
<HR>
<A HREF="book-ora086.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="book-ora088.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
